The majority of smart field devices installed worldwide are HART-enabled, whereas the HART (Highway Addressable Remote Transducer) Protocol is a global standard for sending and receiving digital information across analog wires between smart devices and a control or monitoring system. More specifically, HART is a bi-directional communication protocol that provides data access between intelligent field instruments and host systems.
In networks, wireless communication is widely used and therefore the WirelessHART technology is likewise widely used and provides a robust wireless protocol for the full range of process measurement, control, asset management applications, device parameterization, and device monitoring and diagnosis.
Based on the proven and familiar HART Communication Protocol, WirelessHART enables users to quickly and easily gain the benefits of wireless technology while maintaining compatibility with existing devices, tools, and systems.
In WirelessHART, the traffic during plant operation consists of few but periodic cyclic burst commands to or from each device. With a plurality of such devices sharing the same (wireless) medium, a significant overall amount of bandwidth is statically reserved and/or thus blocked for other applications, while the individual device can only access a fraction of this overall bandwidth. The existing WirelessHART Network Managers optimize the mesh bandwidth toward this communication pattern.
In comparison, when a user or system function executes a commissioning, diagnosis, or monitoring use-case, this may require a large amount of usable bandwidth to a single device, at an unpredictable point in time, and still expect a fast response. This only occurs acyclically, and the existing WirelessHART Network Managers do not optimize for this communication pattern; they only reserve very little bandwidth for it.
In either case, the actual use of bandwidth does not have any noticeable effect on the schedule; for instance, Network Managers do not dynamically adjust bandwidth to acyclic access. Bandwidth can only be requested explicitly by a number of standard HART commands.
In other words, a drawback with current WirelessHART implementations is that the schedules in WirelessHART are not optimized for acyclic data access; neither do the Network Managers dynamically adjust to this communication pattern (at least with sufficient adaption time). Native WirelessHART devices or their device tools can request additional bandwidth from the Network Manager to still speed up occasional acyclic data access since they are aware of these details of the WirelessHART protocol.
In adapter retrofit scenarios or when using generic HART Device DTMs/FDI packages, the device tools have no knowledge of the wireless network. The only wireless-aware components are the gateway/adapter or their respective software tools.
This means that there is no device-specific component that can automatically adjust the bandwidth between the device and gateway to the amount of transmitted data by using the above-mentioned explicit commands. Statically allocating more bandwidth for acyclic data transfer to each device would still be a suboptimal solution because even more bandwidth is then permanently reserved and/or blocked for other use; furthermore, each device would still get access to only a fraction/share of the theoretically available overall bandwidth.
Particularly for full upload/download sequences, the user faces a high latency even though large amounts of bandwidth may be available in the network.